Google一直從使用者角度來思考使用者要的是什麼,而我們都似乎缺乏在做一件事時,探詢最基本的思想。
還記得有一年一位承辦對岸某盛大歌劇的訂票系統的人,告訴我當他們在制訂該訂票系統時的一切過程與找尋一個可以承受大量使用者的資料庫軟體。最後,當他們看過了這些資料庫公司的提案與架構之後,他們最後決定自己開發。原因是這些知名的資料庫公司都無法符合一次多人上線與即時準確比對多座位與訂位(利用最少網路資源,建置最少的硬體設備...等)的重要因素。最後花費最少的預算建置了當時在對岸的第一場世界型大歌劇售票系統。
我在仔細的觀看Google Chrome的介紹影片,瀏覽器背後的故事著實令人感動。在電腦化主導我們資訊獲得、資料統計、資料儲存、資料發表的現在,雖過了這數十年來的演化發展,電腦對於多數使用者來說仍然是一個極高的門檻。而就像是絕大多數的使用者在使用電腦上所提供的功能是極少使用到進階的功能,而所有人則是希望速度與方便性,而速度由硬體廠商在每隔一季就推出一個新的速度,但是軟體的廠商也因為有新速度、新儲存容量而無限加大軟體所佔有的資源,而對使用者來說...這些...就成為困擾,因為他只要做一小件事,但是卻要開啟佔據龐大資源、拖慢速度的軟體與附加程式的應用軟體,而這也包含了所以資訊提供者所提供的資訊也來佔據電腦資源,更加讓一部電腦...龜速化。
當初拋棄IE選用Firefox是因為他所佔據的系統資源少,當Firefox3.0產出後也不多加思索的安裝,但是最後當我在查詢IE 7與Firefox3.0的系統資源時發現Firefox3.0也是一個龐然大物...
許多的消費者的心聲,正如Google Chrome的開發人員所說的需求,瀏覽器要因應新的網頁需求、減少與應用程式的連結...其實,多數消費者要的其實不多,但是多數應用程式卻提供太多消費者所不需要接觸的功能,消費者不會去管他可以接觸到什麼樣進階的資訊而滿足,而這樣的滿足來自於開發人員的心理最底層發表慾望,但是這樣的不必要的負擔卻讓消費者去承擔。
就像是售票系統,消費者要得是即時的看到圖形化的座位資訊,而下訂單時系統不因為圖形介面傳輸速度過慢,而尚失掉爭取好位置的的時機,不會因為網路的擁擠停頓而在訂票過程中重複訂票或遺失個人資訊...
多數消費者其實要得不多,而程式開發人員是否在消費者所可以接觸的介面上提供給他一個方便、快速的介面,前台提供方便介面,而背後系統的繁複卻不用給消費者太多知道的負擔。
你提的例子,後來是他們自己開發一個資料庫軟體嗎?!就是像Oracle, DB2這樣的系統嗎
最後是否用現成付費資料庫或自己開發資料庫、還是免付費資料庫,這我就不太清楚,但是當時付費資料庫的設計,的確吃掉許多的運算資源與網路資源(在當時大陸還在撥接上網為主要上網方式)。
那我覺得這只是規劃上有問題而已,坦白說,前端接單跟後端資料庫分開後,傳輸資料量其實是看應用程式要怎樣處理了...
<pre class="c" name="code">...原因是這些知名的資料庫公司都無法符合一次多人上線與即時準確比對多座位與訂位...
感覺這些敘述有點奇怪,因為這樣的需求跟資料庫軟體本身沒有直接關係。
可能比較關鍵的是後面括號說的(利用最少網路資源,建置最少的硬體設備...等),願意買的硬體無法支撐資料庫的效能
在對岸撥接上網的時代,許多的資料還是整頁發送...那速度真是...比烏龜還慢...,所以一個報價約200萬人民幣跟最後自己建置只花約20萬人民幣,且解決更新資料時只針對資料修改處(非整頁發送),這差很多吧?
恩,的確,所以,應該是整個環境條件影響的關係,不一定能用我們知道的原因去考慮.^^
我知道大陸有段時間是完全崇拜PowerBuilder, 但這是開發工具,如果都只是用現成,而不是自己解決,那只能說客戶沒有掌握到自己的需求跟沒有足夠的要求能力
其實看到這裡,我要說撥接不是錯!
以前我在法國看到一台雷達也只用一條電話線傳送雷達追蹤資料,一分鐘20轉,跟蹤200個目標,其實電話線也綽綽有餘!看你怎樣處理資料傳送而已啦!
如果你都只會用廠商提供的開發工具,而不是自己本身會去掌握問題與關鍵,那...其實也只好任人魚肉!
所以,知道自己需求的客戶,就可以擺脫廠商的束縛,找到自己的解決方案。